1. Field of the Invention
The present invention relates to a packet transmitting method for transmitting and receiving packets among a plurality of data terminals, and a relaying device and a data terminal used for the packet transmission.
2. Description of Related Art
Recently, a demand for transmitting through the Internet such data as video data or audio data, which requires a real time transmission, has been intensified.
As a protocol to meet the demand, an RTP (Real-time Transport Protocol) is ruled by the RFC (Request For Comment) 1889, which was issued by the IETF (Internet Engineering Task Force), a group for standardizing the Internet. The RTP has functions such as 1) specification of a payload type, 2) designation of a sequence number, and 3) designation of a timestamp. These rules enable such information as audio and video data to be transmitted in real time on the Internet. Usually, the RTP is used as an upper layer for the IP (internet protocol) on a network layer and the UDP (User Datagram Protocol) on a transport layer.
FIG. 11A shows contents of an RTP header, UDP header, and IP header (hereafter, referred to as xe2x80x9cRTP/UDP/IP headersxe2x80x9d) attached to data, such as audio and video data, to be transmitted according to the RTP, UDP and IP. Hereinafter, a packet including the RTP/UDP/IP headers is called an IP packet.
As shown in the drawing, the IP header needs 20 bytes, the UDP header does 8 bytes, and the RTP header does 12 b bytes, thus the total amount of RTP/UDP/IP headers reaches 40 bytes. In contrast, video data contained in one IP packet comprises, for example, about 50 bytes. For transmitting such image data in the form of packets, the overhead reaches therefore no less than 44 percents. Similarly, for transmitting audio data which comprises 20 bytes in one packet, the overhead reaches as much as 66 percents. Since a practical transmission needs headers for other layers to be added, the whole headers occupy a large percentage of one packet, thereby causing a drawback of reducing efficiency in communication.
As one technique to overcome the drawback, the RFC2508 issued by the IETF shows an RTP compression protocol to compress the RTP/UDP/IP headers. The RTP compression protocol permits the RTP/UDP/IP headers shown in the FIG. 11A to be compressed into a header exemplified in FIG. 11B (hereinafter referred to as a xe2x80x9ccompressed headerxe2x80x9d). This compression will be detailed as follows.
The method of the compression is applied between two nodes on a network through which packets are transmitted among a plurality of data terminals, for example. More specifically, of the two nodes, one node (hereinafter referred to as a xe2x80x9csender nodexe2x80x9d) converts the RTP/UDP/IP headers of one part of the IP packets communicated among the data terminals into a compressed header, and transmits it, as a header-compressed packet, to the other node (hereinafter referred to as a xe2x80x9creceiver nodexe2x80x9d). Concurrently, the sender node transmits the RTP/UDP/IP headers of the other part of the IP packets to the receiver node, as a full-header packet without any compression. The receiver node decompresses (i.e., restoration) to an IP packet the header-compressed packet or the full-header packet received from the sender node, and sends it to the next node or a receiver data terminal. The full header is a header in which lengths included in the RTP/UDP/IP headers shown in FIG. 11A are replaced by information including a CONTEXT_ID for identifying the RTP connection and a link sequence number link_seq, a serial number, given in the order of transmission from the sender node.
The content of the compressed header shown in FIG. 11B will now be explained. The data of sections with dense hatching applied in the RTP/UDP/IP headers in FIG. 11A, which includes a version number (V) written in the IP header and the payload type written in the RTP header, are constant data (hereinafter referred to as xe2x80x9cstatic fieldsxe2x80x9d) for each packet to be transmitted from the sender node. Hence, as illustrated in FIG. 11B, the compressed header does not include data of the static fields. When the sender node sends the first IP packet of the packet stream to the receiver node, it sends a full-header packet which has a full header including the static fields. After this, the sender node converts the RTP/UDP/IP headers of the succeeding IP packets into a compressed header with no static fields included. The thus-converted compressed header is sent to the reception node as a header-compressed packet. When the receiver node receives the full header packet corresponding to the first IP packet, the receiver node restores the received RTP/UDP/IP headers with reference to the full header in the first received full-header packet, and writes the thus decompressed headers into an internal storage device. After this, the receiver node uses the static fields of the RTP/UDP/IP headers so as to restore the static fields of the compressed header in the header-compressed packets that will be received successively after the first packet.
The data in the static fields are not always constant over all the IP packets, but might be changed in a certain IP packet. If such a change occurs in a certain IP packet, the sender node will transmits a full header packet including a full header corresponding to the RTP/UDP/IP header of the IP packet to the receiver node, without compression.
The data in the sections with no hatching applied in the RTP/UDP/IP headers shown in FIG. 11A include the sequence number and timestamp of the RTP header as well as the ID of the IP header. The timestamp indicates the time at which a packet is transmitted or generated. Such data are expected to have constant difference values (changed amounts) between successive two IP packets transmitted in turn. Hereinafter, fields providing such data are referred to as xe2x80x9cdelta fields.xe2x80x9d As shown in FIG. 11B, the basic compressed header does not include the data in the delta fields. As described above, the receiver node, which holds RTP/UDP/IP headers in its storage device, adds difference values, which have been previously obtained, respectively to the values in the corresponding delta fields of the stored RTP/UDP/IP headers, thus being able to decompress delta fields of compressed headers which will consecutively be received thereafter.
However, it is not always true that the difference values in the delta fields are constant between all the IP packets. There are some cases where changes are made to their difference values. In such cases, changed difference values have to be notified to the receiver node. The receiver node is able to restore the contents in the delta fields contained in the RTP/UDP/IP headers of each header-compressed packet which will be received thereafter, with reference to the contents of the RTP/UDP/IP headers held in the storage device and the newly notified difference values. For this purpose, the compressed header shown in FIG. 11A has flags S, T and I that represent whether the difference values in the delta fields are changed or not. If any difference values are changed, the new difference values are added to the compressed header, as shown by the dotted lines in FIG. 11B. Practically, if there is a change in the difference value of the sequence number of the RTP header, xe2x80x9c1xe2x80x9d is set to the flag S and a sequence number difference value (delta RTP sequence) showing the new difference value of the sequence number is added to the compressed header, as shown by the dotted line in FIG. 11B. Similarly, if there is a change in the difference value of the timestamp of the RTP header, xe2x80x9c1xe2x80x9d is set to the flag T, and a timestamp difference value (delta RTP timestamp) showing the new difference value of the timestamp is included in the compressed header, as shown by the dotted line in FIG. 11B. Further, if there is a change in the difference value of the ID of the IP header, xe2x80x9c1xe2x80x9d is set to the flag I, and an ID difference value (delta IP ID) showing the new difference value of the ID is attached to the compressed header.
As shown in FIG. 11B, the compressed header further includes the CONTEXT_ID and link_seq, like the full header. The receiver node decompresses the compressed header in compliance with the contents of RTP/UDP/IP headers specified by the CONTEXT_ID. The receiver node refers to the link sequence number link_seq of each packet (header-compressed packet or full-header packet) sent in order from the sender node. When it is found that some link sequence numbers are dropped, the receiver node determines that the packets are lost between the sender and receiver nodes.
Referring to FIG. 12, procedures made for packet transmission between the sender and receiver nodes will now be described. In FIG. 12, a field A shows a static field of the RTP/UDP/IP headers (i.e., any of the data with the dense hatching applied in FIG. 11A), and a field B shows a delta field (i.e., any of the data with no hatching applied in FIG. 11A). Further, in FIG. 12, xe2x80x9cFxe2x80x9d represents a full-header packet, while xe2x80x9cCxe2x80x9d represents a header-compressed packet.
When receiving an IP packet a transmitted from a sender data terminal to a receiver date terminal, the sender node stores the RTP/UDP/IP headers of the IP packet a into its internal storage device. Concurrently, the sender node produces a full header by substituting lengths in the headers for a CONTEXT_ID and link sequence number link_seq, and transmits to the receiver node the full header packet including both the produced full header and data (hereinafter referred to as an xe2x80x9cRTP payloadxe2x80x9d), which is the part of the IP packet excluding the RTP/UDP/IP headers (refer to xe2x80x9cOP1xe2x80x9d in FIG. 12). The receiver node which received this full-header packet restores the RTP/UDP/IP headers from the full header of this packet (namely, the CONTEXT_ID and link_seq are extracted from the full header), and transmits the IP packet with this header to the next node or a receiver data terminal. In this operation, the decompressed RTP/UDP/IP headers are stored into its internal storage device.
The sender node then converts the RTP/UDP/IP headers in an IP packet b received after the IP packet a into a compressed header, and transmits the packet b with the compressed header to the receiver node (refer to xe2x80x9cOP2xe2x80x9d in FIG. 12). In the compressed header in the header-compressed packet, a difference value xcex94B(=1) between a value [1] in the delta fields B of the packet b and a value [0] in the delta fields B of the last packet a is added, while a value of xe2x80x9c1xe2x80x9d is set to the flags (flags S, T and I shown in FIG. 11B) that represent changes or non-changes in the difference value.
The receiver node, which received the header-compressed packet b, obtains the delta fields B of the packet b by adding the difference value xcex94B notified in this packet to the values of the delta fields B of the RTP/UDP/IP headers of the last IP packet a stored in the internal storage. The receiver node then transmits an IP packet b having both of the RTP/UDP/IP headers, which include the delta fields B and the static fields A of the RTP/UDP/IP headers extracted from the IP packet a, and the RTP payload. The RTP/UDP/IP headers referred in decompressing the IP packet b (in this case, the RTP/UDP/IP headers of the last IP packet a) is specified by the CONTEXT_ID of the header-compressed packet b. The RTP/UDP/IP headers of the IP packet b and the difference value xcex94B notified in this packet are also stored in the internal storage.
When next receiving an IP packet c, the sender node calculates a difference value between values of delta fields B of both of the IP packet c and the last IP packet b. The difference value xcex94B is [1] (=3xe2x88x922) in this case, which is the same as the previous one notified to the receiver node last time. Therefore, there is no need to newly notify the receiver node of the unchanged difference value. Hence, the sender node transmits to the receiver node a header-compressed packet c having a compressed header with no difference value (i.e., information shown by the dotted line in FIG. 11B (refer to xe2x80x9cOP3xe2x80x9d in FIG. 12). The receiver node that received this header-compressed packet c adds the stored difference value xcex94B to the delta fields B of the previous packet b, thereby decompressing the delta fields B of this compressed header of the header-compressed packet. Then the receiver node sends an IP packet c composed of both RTP/UDP/IP headers, including the decompressed value and the static fields A extracted from the full header of the full-header packet a, and RTP payload. The next packet d is processed similarly.
The delta fields B of an IP packet e next received by the sender node is [5] in value, of which difference value from the delta fields B of the last IP packet d is [2]. When the difference value xcex94B is changed in this way, the sender node transmits a header-compressed packet e having a compressed header in which the changed new difference value is added and the corresponding flag is set to [1]. The receiver node adds the newly notified difference value to the values of the delta fields B of the IP packet d so as to decompress the delta fields B of the packet e, then transmits an IP packet containing the decompressed delta fields B.
The sender node then receives an IP packet g, which is different in the static field A from the last IP packet e. Thus, in this case, the sender node does not compress the RTP/UDP/IP headers of this IP packet and transmits a full-header packet g having a full header in which the lengths in the RTP/UDP/IP headers of the packet g is replaced by the CONTEXT_ID and link_seq. The receiver node that received this full-header packet g converts the full header into the RTP/UDP/IP headers and memorizes them in the internal storage.
The header compression method ruled by the RFC2508 has been described above (hereinafter referred to as a xe2x80x9cmethod Axe2x80x9d). However, this compression method has been suffering from some drawbacks, which will be described as follows.
For instance, as shown in FIG. 13, an assumption is made that the header-compressed packet c is lost between the sender and receiver nodes for some reason. As described above, when decompressing the packet d, the receiver node adds the difference value xcex94B to the delta fields B of the IP packet c to decompress the delta fields B of the IP packet d. As a result, when the header-compressed packet c is lost, it is impossible to decompress the delta fields B of the header-compressed packet d. The receiver node is therefore forced to discard packets d, e and f shown in FIG. 13, which are received until the next full-header packet g. In other words, the loss of the packets causes consecutive losses of some other packets, which leads to reducing a throughput compared to a method in which the header compression is not involved. In particular, in cases the sender and receiver nodes are connected by a wireless link, a packet is likely to be lost in the wireless link. If such a loss occurs, some other packets are frequently discarded at the receiver node. As a technique to resolve such a problem, the RFC 2507 and 2508 issued by the IETF and the Internet-Draft provide the following methods.
Method 1: Repetitive transmission of full-header packet (RFC 2507)
In the case of the foregoing conventional method A, the sender node transmits a full-header packet only when the static fields of a header change in value. In contrast, as shown in FIG. 14, this method 1 selects several IP packets to be transmitted every predetermined number of packets, regardless of whether the static fields change in value or not. And the selected IP packets are converted to the full header packets with full headers and the full header packets are transmitted to the receiver node, while the remaining IP packets are converted to header-compressed packet with compressed headers and the header-compressed packets are transmitted to the receiver node. In the method A, since full-header packets are not transmitted to the receiver node as long as their static fields do not change in value, all the packets transmitted after the occurrence of loss of a packet are discarded. In contrast, the present method 1 allows a full-header packet to be transmitted at intervals, so that it has the advantage that the number of packets discarded owing to the loss of the packets can be lowered. However, the present method 1 has trade-offs that a longer period for transmitting full-header packets results in that the number of packets discarded is raised, whilst a shorter period for transmitting full-header packets results in that a large number of full-header packets with large overheads are transmitted, reducing efficiency in communication.
Method 2: Request for full headers through back channel (RFC 2507 and 2508)
As shown in FIG. 15, when detecting the loss of a packet, the present method 2 permits the receiver node to transmit a CONTEXT_STATE, a message to request a full-header packet for the sender node. When receiving the CONTEXT_STATE, the sender node transmits the next IP packet to the receiver node in the form of a full-header packet. As a result, an interval during which some packets are discarded due to the loss of a certain packet can be limited to the interval between the occurrence of the packet loss and the reception of a full-header packet transmitted in response to the CONTEXT_STATE. Nevertheless, the present method has a drawback that as the interval between the transmission of the CONTEXT_STATE and the reception of a full-header packet at the receiver node, that is, an RTT (Round Trip Time), becomes larger, the number of packets discarded are also raised. For communicating packets by way of a wireless link, such a drawback becomes noticeable, because the RTT of the wireless link is very long.
Method 3: Twice algorithm (RFC 2507)
According to the present method 3, the compressed headers of header-compressed packets received after the loss of a certain packet are decompressed using the RTP/UDP/IP headers decompressed most lately before the occurrence of loss of the packet. For example, as shown in FIG. 16, it is assumed that after a packet b is received in order, a packet c is lost, and then a packet d is received in order. In this situation, when a difference value xcex94B is unchanged in value over the packets b to d, the delta fields B of the packet d can be calculated by adding a value of double xcex94B to the delta fields B of the packet b. Moreover, the present method needs the UDP checksum included in a compressed header (refer to FIG. 11B), so that the UDP checksum is used to determine if packets were decompressed correctly. However, as shown in FIG. 16, in cases where a packet k is lost and difference values xcex94B of the delta fields between packets j and k change, there is the problem that a packet l received immediately after the packet loss cannot be decompressed correctly. In particular, in the case that packets are communicated via a wireless link, there is a possibility that packets are lost in sequence (namely, over a long interval). Under such a situation, it is considered that difference values xcex94B are likely to change for a large number of lost packets. Therefore the foregoing problem is amplified.
Method 4, ROCCO (Internet-Draft)
According to the present method 4, the difference value xcex94B can be estimated on a characteristic of a media through which packets are transmitted. For example, in the case of FIG. 17, it is assumed that packets g and h are lost and difference values xcex94B between the packets g and h change. In this case, changes in the difference values xcex94B are estimated on a characteristic of a media through which packets are transmitted, and a packet can be decompressed through addition of the estimated difference value xcex94B to the packet f. Additionally, the present method uses an error detecting code (CRC) to confirm if the decompression is performed correctly or not. Thus, even if the difference value xcex94B changes, the present method enables packets received after the loss of a certain packet to be decompressed. However, the present method involves a difficulty in how the difference value xcex94B is estimated.
As described above, although a variety of techniques have been proposed to efficiently perform data communication even when RTP/UDP/IP headers of IP packets are compressed, any technique has some drawbacks. Thus, it is a present situation that there is a limitation in effectively reducing the number of packets to be discarded owing to the loss of a certain packet that has been caused between the sender and receiver nodes.
The present invention has been made in view of the foregoing circumstances. An object of the present invention is to provide a packet transmitting method, a relaying device and a data terminal capable of effectively reducing the number of packets to be discarded due to the loss of a certain packet, even if headers of packets to be transmitted and received are compressed.
According to one aspect of the present invention, an object of the present invention is achieved by a packet transmitting method comprising the steps of a packet transmission by a communication apparatus provided on a transmission node in a network, the packet transmission including an operation for converting a plurality of non-compressed packets to be transmitted into either a full-header packet with a full header or a header-compressed packet with a compressed header and transmitting a converted packet to a receiver node in the network; and a packet reception by a communication apparatus provided on the receiver node, the packet reception including an operation for receiving the full-header packet or the header-compressed packet transmitted from the sender and an conversion for converting a received packet to a decompression packet, the conversion including an operation for keeping, in cases a full-header packet or header-compressed packet is lost during transmission from the sender node to the receiver-node, at least one header-compressed packets received during a period between an occurrence of a packet loss and a reception of a next full-header packet, and an operation for decompressing a compressed header of the header-compressed packets thus kept, based on a content of a full header of the full-header packet received after the packet loss.
In the method, header-compressed packets received until the earliest reception of a full-header packet after the loss of a packet are kept, and the compressed headers of the header-compressed packets thus kept are decompressed based on the contents of the full-header packet. As a result, compared to the foregoing prior art, the number of packets discarded due to the packet loss can be lowered.
The present invention further provides a packet reception method comprising the steps of receiving a full-header packet with a full header or a header-compressed packet with a compressed header and converting a received packet into a decompressed packet; keeping, in cases the full-header packet or header-compressed packet is lost before being received, header-compressed packets received during an interval between the loss of the packet and a reception of a next full-header packet after the loss; and decompressing a compressed header of each of the header-compressed packets kept, based on a content of a compressed header of a full-header packet received after the loss of the packet.
The present invention can be embodied so as to produce or sell the relay apparatuses or the data terminals for transmitting packets in accordance with the packet transmitting method of the present invention. Furthermore, the present invention can be embodied so as to record the program executing the packet reception method of the present invention into storage media readable by computers, and deliver the media to users, or provide the program to users through electronic communication circuits.